ASICs includes general circuits, such as logic, memory, and input/output (“I/O”) ports, it also includes a specialized function circuit to implement a special function that the circuits cannot perform. For instance, the specialized function circuit might implement analog or mixed analog/digital circuitry, whereas the circuits might be limited to only digital circuits. In other cases, the specialized function circuit can implement a Peripheral Component Interconnect Express (“PCIe”) physical layer (“PHY”), or any other complex, highly dense circuit.
One drawback to providing the specialized function circuit is that current in-circuit verification techniques are generally not comprehensive enough to emulate the functionality of the specialized function circuit in a target circuit (i.e., for a specific application). In particular, most conventional in-circuit verification techniques limit verification to the emulation of the functionalities provided by the circuits of an ASIC, thereby neglecting verification of the specialized function circuit and its interaction with the circuits. This can leave ASICs vulnerable to undetected errors. Some conventional approaches verify the design of ASICs by applying stimuli from a software-based simulator to an ASIC and the specialized function circuit. In this case, the functionality of ASIC is modeled in software. Typically, the stimuli mimic the functionality of a target circuit. Although functional, software-based simulators lack the capabilities to thoroughly test real-world applications, especially in their native environments. In practice, the amount of computer time used for software simulation limits the degree to which the design is verified. Another drawback is that normal design verification processes omit in-circuit emulation and/or verification as a part of the suite of tests in design verification. Without in-circuit verification, the problem of transferring undetected errors into a fabricated ASIC is exacerbated by the lack of exhaustive simulations.
FIG. 1 is a conventional process flow 100 for verifying designs in ASICs prior to fabrication of a device. A designer creates a design by establishing a hardware description language (“HDL”) description of that design in, for example, a register transfer language (“RTL”) at 101. The conventional flow is as follows: initial RTL is generated at 101, with subsequent test bench simulation performed at 104. If bugs are found at 115, then flow 100 iterates (i.e., regenerates) RTL and performs additional simulations. When bugs are not found, then flow 100 moves to 105 at which place and route is performed, followed by static timing analysis at 106. Note that timing is not met at 107, then flow 100 iterate RTL back at 101. A drawback to flow 100 is that test bench simulations at 104, as well as other software-based simulators, cannot readily detect errors that otherwise might be detectable during testing in real-time applications. Another drawback of relying on testbench verification is that there are combinations of inputs that are too numerous to test. Regardless of the uncertainties on how specialized function circuits and other ASIC circuits will interact collectively or individually in a real-time application, conventional flow 100 moves to 108. Here, an ASIC device is fabricated at 108. It is not until after fabrication that errors arise that otherwise would have been detectable by in-circuit verification. Consequently, additional resources, efforts, time and costs must be invested to rectify those errors found in the first silicon version of the device.
In view of the foregoing, it would be desirable to provide an in-circuit design and verification device, system and method that minimize the above-mentioned drawbacks, thereby facilitating expeditious design verification of ASIC devices.